chore(mix_generator): clear the DCM backlog in mix_generator and mix_annotations - #1032
Merged
Conversation
…annotations `melos run analyze` failed on these two packages. CI never caught it: the test workflow runs analyze:dart but deliberately skips analyze:dcm because DCM needs CI credentials, so the backlog only surfaced when someone ran it locally. `dcm fix` handled five mechanical issues (four blank-line-before-return, one member ordering). The rest needed a decision: - MixWidgetBuilder interpolated a nullable targetTypeReference into the generated widget name. It was guarded by `hasDirectTarget`, so it could not actually be null, but nothing made that checkable. Bind the value at the call site instead and pass it in non-null; a null there would have emitted `null(...)` as a widget name. `hasDirectTarget` had no consumers left, so it is gone rather than left dead. - _targetStyleAcceptsRecipe interpolated a nullable spec.name into a type string it then compares. Both remaining checks match by name, so an unnamed element can never match: hoist the name and return false when it is absent. - The "must include required factory parameter" diagnostic interpolated a nullable parameter name and would have read "parameter `null`" for a wildcard parameter. Fall back to the analyzer's displayName. - MixWidget.target keeps `Function?`: a constructor tear-off's signature differs per annotation, so no explicit function type fits, and Object? would drop the callable signal. MixableSpec.target already carried this ignore; MixWidget's had just been missed. Added with the rationale. No behavior change: a full `melos run gen:build` regenerates every package byte-for-byte identically.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
melos run analyzefailed onmix_generator(10 issues) andmix_annotations(1). This clears both, somelos run analyzepasses across the workspace for the first time.Split out of #1031, which is unrelated grid work — these files aren't touched there.
Why it accumulated
CI never runs DCM.
.github/workflows/test.ymlrunsformat:check,schema:inventory,analyze:dart, andci, with a comment explaining the omission: "DCM requires CI credentials." Somelos run analyze:dcmonly ever runs on someone's laptop, and there are no git hooks in the repo. Worth a follow-up decision — see below.For the record, the rest of the local-lint surface was already clean:
dart format --set-exit-if-changedreports 0 changed files across all 11 packages plusscripts, anddart fix --dry-runreports "Nothing to fix!" in every package. This is DCM-only.Mechanical (via
dcm fix)Four
missing blank line before return, onemember-ordering.Judgement calls
MixWidgetBuilderinterpolated a nullabletargetTypeReferenceinto the generated widget name. Guarded byhasDirectTarget, so it couldn't actually be null — but nothing made that checkable, and a null would have emittednull(...)as a widget name in generated code. Now bound at the call site with a pattern match and passed in non-null.hasDirectTargethad no consumers left afterward, so it's removed rather than left dead._targetStyleAcceptsRecipeinterpolated a nullablespec.nameinto a type string it then compares against. Both remaining checks match the spec by name, so an unnamed element can never match — hoisted the name and returnedfalsewhen absent.The "must include required factory parameter" diagnostic interpolated a nullable parameter name, so a wildcard (
_) parameter would have producedparameter `null`. Falls back to the analyzer'sdisplayName.MixWidget.targetkeepsFunction?. A constructor tear-off's signature differs per annotation, so no explicit function type fits, andObject?would drop the callable signal.MixableSpec.targetalready carried this exact ignore;MixWidget.targethad simply been missed. Added with the rationale._extractFactoryParamsbuiltavailableNamesunconditionally though it's only read in the!includesAllbranch — moved inside it.Verification
melos run gen:buildregenerates every package byte-for-byte identically — no behavior change, which is the point that matters for a generator refactormelos run analyze— SUCCESS (dart + DCM + schema inventory), previously FAILEDmelos run ci— all green (mix 2892, mix_winds 532, mix_protocol 391, mix_generator 377, mix_chart 52, mix_lint 37, + examples)melos run format:check— cleanNo CHANGELOG entries: generated output is unchanged, so nothing here is user-visible.
Follow-up worth deciding
These will drift back. With DCM intentionally out of CI, the only enforcement point is local, and the repo has no git hooks at all — no husky, no lefthook, no
core.hooksPath. Options are DCM CI credentials, or a pre-commit/pre-push hook runningmelos run analyze:dcm. Happy to wire up whichever you prefer.